<i>Trace++</i>: A Traceability Approach for Agile Software Engineering

Agile methodologies have been introduced as an alternative to traditional software engineering methodologies. However, despite the advantages of using agile methodologies, the transition between traditional and agile methodologies is not an easy task. There are several problems associated with the use of agile methodologies. Examples of these problems are related to (i) lack of metrics to measure the amount of rework that occurs per sprint, (ii) interruption of a project after several iterations, (iii) changes in the requirements, (iv) lack of documentation, and (v) lack of management control. In this paper we present Trace++, a traceability technique that extends traditional traceability relationships with extra information in order to support the transition between traditional and agile software development. The use of Trace++ has been evaluated in two real projects of different software development companies to measure the benefits of using Trace++ to support agile software development

An Evaluation of Design Rule Spaces as Risk Containers

It is well understood that software development can be a risky enterprise and industrial projects often overrun budget and schedule. Effective risk management is, therefore, vital for a successful project outcome. Design Rule Spaces (DRSpaces) have been used by other researchers to understand why implemented software is error-prone. This industrial case study evaluates whether such spaces are durable, meaningful, and isolating risk containers. DRSpaces were created from UML class diagrams of architectural design artefacts. In our study, object orientated metrics were calculated from the UML diagrams, and compared to the error-proneness of the DRSpace implementation, to determine whether architectural coupling translated into implementation difficulties. A correlation between architectural coupling and error-proneness of DRSpaces was observed in the case study. Software developers were asked to identify DRSpaces they found difficult to implement, in order to understand which factors, other than architectural coupling, were also important. The qualitative results show agreement between the code areas developers found difficult to implement and the error-prone DRSpaces. However, the results also show that architectural coupling is just one risk factor of many. The case study suggests that architectural DRSpaces can be used to facilitate a targeted risk review prior to implementation and manage risk

Towards a Framework for Managing Inconsistencies in Systems of Systems

The growth in the complexity of software systems has led to a proliferation of systems that have been created independently to provide specific functions, such as activity tracking, household energy management or personal nutrition assistance. The runtime composition of these individual systems into Systems of Systems (SoSs) enables support for more sophisticated functionality that cannot be provided by individual constituent systems on their own. However, in order to realize the benefits of these functionalities it is necessary to address a number of challenges associated with SoSs, including, but not limited to, operational and managerial independence, geographic distribution of participating systems, evolutionary development, and emergent conflicting behavior that can occur due interactions between the requirements of the participating systems. In this paper, we present a framework for conflict management in SoSs. The management of conflicting requirements involves four steps, namely (a) overlap detection, (b) conflict identification, (c) conflict diagnosis, and (d) conflict resolution based on the use of a utility function. The framework uses a Monitor-Analyze-Plan- Execute- Knowledge (MAPE-K) architectural pattern. In order to illustrate the work, we use an example SoS ecosystem designed to support food security at different levels of granularity

Identifying Conflicting Requirements in Systems of Systems

A System of Systems (SoS) is an arrangement of useful and independent sub-systems, which are integrated into a larger system. Examples are found in transport systems, nutritional systems, smart homes and smart cities. The composition of component sub-systems into an SoS enables support for complex functionalities that cannot be provided by individual sub-systems on their own. However, to realize the benefits of these functionalities it is necessary to address several software engineering challenges including, but not limited to, the specification, design, construction, deployment, and management of an SoS. The various component sub-systems in an SoS environment are often concerned with distinct domains; are developed by different stake-holders under different circumstances and time; provide distinct functionalities; and are used by different stakeholders, which allow for the existence of conflicting requirements. In this paper, we present a framework to support management of emerging conflicting requirements in an SoS. In particular, we describe an approach to support identification of conflicts between resource-based requirements (i.e. requirements concerned with the consumption of different resources). In order to illustrate and evaluate the work, we use an example of a pilot study of an IoT SoS ecosystem designed to support food security at different levels of granularity, namely individuals, groups, cities, and nations

QoS-driven proactive adaptation of service composition

Proactive adaptation of service composition has been recognized as a major research challenge for service-based systems. In this paper we describe an approach for proactive adaptation of service composition due to changes in service operation response time; or unavailability of operations, services, and providers. The approach is based on exponentially weighted moving average (EWMA) for modelling service operation response time. The prediction of problems and the need for adaptation consider a group of services in a composition flow, instead of isolated services. The decision of the service operations to be used to replace existing operations in a composition takes into account response time and cost values. A prototype tool has been implemented to illustrate and evaluate the approach. The paper also describes the results of a set of experiments that we have conducted to evaluate the work

Decomposing ratings in service compositions

An important challenge for service-based systems is to be able to select services based on feedback from service consumers and, therefore, to be able to distinguish between good and bad services. However, ratings are normally provided to a service as a whole, without taking into consideration that services are normally formed by a composition of other services. In this paper we propose an approach to support the decomposition of ratings provided to a service composition into ratings to the participating services in a composition. The approach takes into consideration the rating provided for a service composition as a whole, past trust values of the services participating in the composition, and expected and observed QoS aspects of the services. A prototype tool has been implemented to illustrate and evaluate the work. Results of some experimental evaluation of the approach are also reported in the paper

Risk Containers – A Help or Hindrance to Practitioners?

Finding problems at the design stage reduces the cost to resolve them. Previous studies have indicated that error-proneness risks can be isolated into risk containers created from architectural designs, to help mitigate such risks early on. Here we describe an ongoing experiment to establish whether presenting designs as a collection of such containers helps practitioners manage the isolated risks. Participants must identify cyclic dependencies that could result in error-proneness and assess the impact of design changes. The emerging results suggest it takes participants longer to locate cyclic dependencies in collections of container diagrams than it does in a single diagram representing the whole design. Participants who reviewed collections of container diagrams tended to identify more cyclic dependencies correctly than those using a single diagram. Although, the results suggest that presenting a design as a collection of containers has no overall bearing on a participant’s ability to correctly identify impacts of design changes, in cases where changes span multiple container diagrams no errors in change impact detection were observed. Errors were observed when assessing the same change using a single diagram representing the whole design